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ABSTRACT 



In a connection management system for setting up connec- 
tions in a communications network, run-lime negotiation is 
carried out to avoid feature interaction. Users of the network 
are provided with user agents (intelligent software) which 
have access to user profiles. When a calling user wants to set 
up a particular connection configuration, which may involve 
service features such as ring back later on busy, their user 
agent sends a connection configuration proposal to the user 
agent for a called user. The two user agents then negotiate to 
establish a mutually acceptable connection configuration, if 
one is available. The negotiation is based on alternative 
connection configurations stored in order of preference in 
the respective user profiles. These are proposed and counter- 
proposed by the user agents in descending preference order 
until the mutually acceptable configuration is reached or the 
connection fails. 

25 Claims, 11 Drawing Sheets 
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Fig.3. 
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Fig.13. 
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PROCESS MANAGEMENT SYSTEM 

BACKGROUND OF THE INVENTION 

The present invention relates to process management 
systems. It finds particular application in the provision of 
services over a communications network, with particular 
reference to feature interaction. 

There are many processes which are complex and which 
can be carried out in more than one way. Embodiments of 
the present invention are intended to select and configure the 
steps in a process. 

An example of a complex process, which can be con- 
trolled by a management system according to an embodi- 15 
ment of the present invention, is that of service provision 
over one or more communications networks. Recently, the 
services available to users over communications networks 
have grown much more sophisticated. For instance, in the 
UK, it is now possible to subscribe to call waiting and 20 
answering services, provided over the public switched tele- 
communications network (PSTN). It is expected that mod- 
ernisation of existing networks, and the provision of new 
networks, will lead to a proliferation of new services. 

Increasingly in the future, different types of services are 25 
likely to be offered over communications networks. For 
instance the increasing capability of technology is enabling 
a future where a wide variety of multimedia services can be 
delivered to users over communications networks. These 
services could include simple voice telephony, multimedia 30 
conference amongst many users, home shopping and video 
on demand. Additionally users may want such services to be 
delivered over a variety of terminal types such as a portable 
phone, portable personal computer and domestic television 
set with a set-top-box. 35 

These services come not only from development of the 
telecommunications environment, including telephony and 
cable television, but also from environments previously 
separate, such as the computing environment. For instance, 
there has been major growth of computer network services, 40 
such as those available on the Internet. Collectively all these 
services are referred to herein as information services. 

Although to date (at least in the telephony world) the 
communication network operator and the service provider 45 
(SP) have generally coincided, this is not essential. Another 
trend expected in the future is that, increasingly, the service 
provider will be separate from the network operator. As in 
the case of Internet, several SPs (vendors) may offer their 
services (products) over a common network. Indeed, there 5Q 
may be further complexity involved in that the "common 
network" might in fact comprise multiple networks con- 
nected together, managed by many different network pro- 
viders. 

Communications services are based on functionality pro- 55 
vided by the network(s) carrying the services. In the tele- 
communications arena, recent developments mean that this 
could be provided increasingly by intelligence, ie decision- 
making software, in an intelligent network architecture. 
With the convergence of computing and telecommunica- 60 
tions technology, however, functionality may in practice be 
provided in other ways. 

Regardless of how functionality will be provided, there 
has emerged a problem of "feature interaction". This arises 
for instance when features which would normally be trig- 65 
gered in provision of one service, conflict with features 
normally triggered in provision of another service and the 
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two services are called on at the same time. A simple 
example of feature interaction is the conflict between "Call 
Forwarding" and "Call Waiting". Clearly a call cannot be 
both forwarded and kept waiting. 

As services grow more diverse, feature interaction has 
been found to be a very complex problem. It is considered 
one of the fundamental obstacles to rapid development and 
deployment of new services. As the number of new features 
grows, the time required to introduce them grows. 

In attempting to solve the feature interaction problem, a 
strategy has been to classify the solutions into avoidance, 
detection and resolution. Avoidance looks at ways to prevent 
undesired feature interactions. Detection assumes that fea- 
ture interactions will be present, and determines methods for 
identifying and locating them. Resolution assumes that 
feature interactions will be present and detected, and looks 
at mechanisms for minimising their potential adverse 
effects. It is not practical to assume that the solution can be 
provided by just one approach. Feature interactions found 
before deployment can be avoided. In contrast, feature 
interactions detected during run-time must be resolved at 
run-time. One advantage of run-time interaction resolution 
is that the problem space is reduced, since only information 
specific to each occurrence of an interaction need be con- 
sidered. 

Current approaches to run-time resolution include event 
based resolution and negotiating software agents. Event 
based resolution is based on an approach of collecting events 
during the basic call process which trigger the activation of 
features. In this way, the feature manager can control which 
features should be invoked. These approaches can resolve 
issues such as signal ambiguities and incompatible combi- 
nations of call-processing activities. An alternative approach 
is to use negotiating software agents proposed by Griffeths 
and Velthuijsen in "The Negotiating Agents Approach to 
Runtime Feature Interaction Resolution", published in 1994 
by IOS Press. This approach uses agents to represent users, 
network providers, and terminals, collectively called enti- 
ties. Users define policies which describe how each feature 
should behave. These policies constrain the set of operations 
that each user or provider is willing to perform in initiating 
or modifying a call. A negotiation mechanism is used to 
resolve conflicts between the policies of different users, thus 
maintaining autonomy amongst the users. 

International patent application WO-A-94/27411 
describes a method of resolving conflicts among entities in 
a distributed system wherein a negotiating software agent 
represents each entity, the method being based upon gen- 
eration of proposals and counter-proposals on the nature of 
a communication session to be established between those 
entities, selected by the agents from a goal hierarchy. A 
single goal hierarchy is used by all the agents involved in 
establishing the session although different agents may mark 
a particular node within the hierarchy acceptable or unac- 
ceptable. On receiving an unacceptable proposal an agent 
may derive, from the goal hierarchy, the overriding goal of 
the user initiating the proposal and hence select a counter- 
proposal from within the same hierarchy. 

In this description the term "agent" relates to a function or 
process which operates in a computing environment and 
which can act autonomously to receive a request for an 
operation and provide a result. An agent normally has an 
up-datable data store for holding data relevant to local 
conditions, and usually also for holding some global infor- 
mation about the disturbed environment in which it sits. 
Agents operate autonomously, having decision-making 
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functionality (intelligence) allowing them to negotiate and invention would include for instance establishing param- 

output a result in response to an incoming message. The eters such as costs and timing for electronic trading and 

result may be for instance a control signal to an apparatus. transfer of funds, establishing access and download of data, 

In the communications environment, the control signal may and information filtering. 

cause a connection to be made according to a particular 5 Embodiments of the present invention are particularly 

configuration. useful when directed to identifying and resolving feature 

Typically, an agent is embodied as a piece of software, for interactions in communications service provision at runtime. 

examplewritt e nintheCprogramminglanguage,runningon According to a second aspect of the present invention, 

a suitable computing plafform, for example a UNIX there is proved a me hod of establishing a connect^n over 

rv a t\u a ,Tr o * j V j in a communications network, for service provision between 

( Irademark) based platform. Requests and results are passed io fifst ^ ^ Qf ^ netWQrk ^ M 

between an agent and a requesting entity, which might be reS pective connection setup means for said users, which 

another agent, across a suitable communications network, method comprises' 

for example a TCP/IP-based local area network, to which the i} storing for each of said ^ data defi • at least Qne 
computing platform is interfaced. In some embodiments, connection configuration- 
plural agents can reside on a common computing platform is fi) stQring in respect of ^ defi . a connection con . 
and, conversely, a single agent can be realised across plural figuration for the second user, data defining at least one 
computing platforms in the environment. Also, the comput- alternative connection configuration; and 
ing environment might be heterogeneous, and support van- iii) storing in respect of said data defining a connection 
ous different types of computing platforms. configuration for the second user, and in respect of the 
SUMMARY OF THE INVENTION 2 ° ^ ata defining the or each of its alternative connection 

configuration(s), a respective priority indicator; 
According to a first aspect of the present invention, there the method further comprising a negotiation process for the 
is provided a method of processing data in data processing establishment of a connection by means of: 
means, so as to generate an output signal in response to at i v ) transmitting data defining a proposed connection con- 
least one input signal, wherein the input signal comprises at 25 figuration from the connection setup means for the first 
least one data element, which method comprises: user to the connection set up means for the second user; 

i) storing a set of data elements; v) reviewing the data defining the proposed configuration 

ii) allocating to each stored data element a weighting at tne connection setup means for the second user by 
factor; accessing the data defining configurations and the 

iii) receiving said input signal; 30 respective priority indicators stored in respect of the 

iv) for each data element of the input signal, searching for .. SeC 1 0nd user ' / nd . . 

that data element in the stored set of data elements; V1 > selectin S transmitting a response to the connection 

s c .1.1 r . i , ■ , . - , setup means tor the first user, the response being 

v) for each data element of the input signal which is found determined at least in part by the result of the review 
by the search in the stored set of data elements, 35 step v) above, and selected from acceptance or rejection 
reviewing the weighting factor allocated to that data of the pr0 p 0S ed connection configuration, or compris- 
element; and ing data defining a counter-proposed connection con- 

vi) generating an output signal determined by the figuration. 

reviewed weighting factors. According to a third aspect of the present invention, there 

Preferably, there are provided at least first and second data 40 is provided apparatus for use in establishing communica- 

processing means, wherein the input signal is received by 'tions connections by means of a communications network, 

the first data processing means from the second data pro- the apparatus comprising: 

cessing means and the output signal is sent by the first data i) first and second network access points; 

processing means to the second data processing means, said ii) at i east one data store for storing user profileSj ea ch 

output signal comprising a response selected from: 45 ^ T profile comprising a set of connection configura- 

a) acceptance; tions associated with a respective user, and for storing 

b) rejection; and priority indicators in relation to at least two of said 

c) a signal comprising at least one data element. connection configurations; and 

In embodiments of the present invention, the data pro- iii) first and second connection set up means for use in 

cessing means for a first entity and a second entity can make 50 establishing connections between said access points, 

proposals and counter proposals to each other over the way wherein said first and second connection set up means are 

in which a process is to be carried out. Each data processing each provided with a negotiation protocol, access to at least 

means looks at its own preferences, the "weighting factors", one user profile in the data store, and means to review said 

for the elements of the proposal incoming from the other priority indicators for that user profile, such that a commu- 

data processing means. If it can put forward a counter 55 nication connection can be set up between the access points, 

proposal which is more acceptable to it in the light of its own on behalf of at least two users, by negotiation between the 

preferences, it will do so and wait for the other data first and second connection set up means, based on the 

processing means to review the counter proposal in its turn, respective user profiles and the related priority indicators, 

against its own preferences. It will be seen that embodiments of the present invention 

Clearly, there will be circumstances where a data pro- 60 allow feature interactions to be circumvented at run-time for 
cessing means accepts a proposal even though it can put a communications service by means of a user being able to 
forward a better proposal from its point of view. For preselect to abandon a service aspect in response to a 
instance, this will happen if it has already had the "better" potential compromise proposal from another user by build- 
proposal rejected, or if the negotiation process has become ing in an order of preference for service aspects, 
too protracted. 65 Significant aspects of preferred embodiments of the 

Processes other than communications service configura- present invention for use in communications service provi- 

tion which might benefit from an embodiment of the present sion arc: 
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the introduction of scheduling so that an otherwise failed Software clearly provides the basis of the infrastructures 

connection can be reattempted needed in service provision systems according to embodi- 

the provision of a preference order for connection con- ments of the present invention to implement scalable and 

figurations deployable solutions. Different types of software technology 

a negotiation strategy which can be varied both in general * be employed, and there are several functional design 

terms and specifically for each user approaches which could be used. However, a common 

, r ... . , . approach to the design and implementation of software 

the facility to send multiple connection configurations systems in this technical environment uses object oriented 

between users, and the negotiation protocol offered software technology. This is known and used by interaa- 

the representation of features as high level goals, tional standards bodies (e.g. Open Software Foundation 

how these high level goals are mapped into a user Object Management Group (OSF OMG), Open Systems 

configuration and Interconnection (OSI)). Reference might be made for 

the way in whi'ch agents, acting on behalf of the users ^^^S^l^^SSI^ 

involved in any given connection, negotiate m the QMG T £ Document 92 11 1 

connection setup process. 15 l n general terms, "objects" in this context comprise units 

Although embodiments of the invention are clearly very of which ^ emities 0f m JJ f ^ feaI 

useful in communications service provision, as described world by means of a combination of data and functionality, 

above, they can also have application in a wide range of Data is encapsulated as internal attributes of an object and 

process environments. Wherever there is a choice in the way the associated functionality is encapsulated as methods 

elements of a process might be carried out, and wherever 20 which use or operate upon the attributes. Although an object 

there are different entities involved in the carrying out of the may receive a message from another object requesting it to 

process, which entities may have different preferences, then perform a method on its attributes which may result in the 

an embodiment of the present invention may be appropriate. return of data, the attributes themselves are not directly 

TERMINOLOGY accessible by external objects. Such high degrees of encap- 

25 sulation have not been readily available in earlier software 

For the purposes of this patent specification, we will technologies, 

define the following terms: Embodiments of the present invention are advantageously 

Feature based on object-oriented technology. 

A feature is a tariffable unit, e.g. Call Waiting. There can From the perspective of the enterprises involved in sat- 

be two types of feature. A technology feature is an individual 30 isfying the overall requirements of users in the future, there 

operation that the platform performs. A policy feature on the are likely to be significant challenges involved in designing 

other hand, is a constraint on the set of operations that a user a suitable infrastructure. A potential starting point would 

or provider is willing to perform in initiating or modifying clearly be provision of an architecture (from high-level 

a call. Embodiments of the present invention relate to this design to low-level implementation) that can technically and 

second type of feature. 35 economically support services of the future. Software and 

Service hardware resources of the computing infra -structure would 

A service is a collection of features. A feature modifies be enabling components of the service architecture. An 

one or more aspects of a service, while using the remaining aspect of the computing infrastructure is the processing 

functionality provided. An example of a service is that environment and a known environment of suitable type for 

currently offered by the present applicant in the UK: "Net- 40 use in embodiments of the present invention is the distrib- 

work Services". This comprises the features "Call Waiting", uted processing environment (DPE) which allows multiple 

"Call Diversion", "3 Way Calling" and others. processes to be run using multiple computer "nodes". The 

Feature Interaction DPE maintains a view of the multiple nodes and processes 

A feature interaction occurs when the behaviour of one and handles message passing between nodes and objects, 

feature affects the behaviour of another feature. 45 providing a common language for the exporting of interfaces 

It should be noted that although the word "call" is used for different objects residing on different nodes. That is, it 

throughout this specification, embodiments of the present assists with aspects of the software and hardware location 

invention should not be taken to be limited to voice or transparency and facilitates the provision of scalable and 

speech transmission. The principles of the invention will deployable solutions. Standards for DPE already exist and 

clearly also be relevant to other transmissions, for instance so are being extended. 

potentially involving data or information transmission. A node in this context might conveniently be provided by 

It is recognised that computing infrastructures in telecom- a computer with processors and memory which is capable of 

munications can become extremely complex and this could running an operating system, compatible distributed pro- 

potentially limit manageability, extendibility, scalability and cessing platform and objects executed as processes on the 

robustness. The approach exploited in embodiments of the 55 computer. 

present invention, which provides simplicity in the Another advantageous characteristic would be that the 

infrastructure, is that of intelligent agent technology, the communication network (or networks) itself is capable of 

basis of which is described in "Distributed Artificial transmitting a wide range of services. There are network 

Intelligence", ed. Huhns M. N., Pitman, London 1987. An technologies which are capable of supporting multiple ser- 

intelligent agent in this context can be broadly described as 60 vice delivery and some examples of these are based on the 

a software based entity which acts on behalf of another asynchronous transfer mode (ATM) and synchronous digital 

entity. It might comprise updatable data, which might only hierarchy (SDH) technologies. A common feature of such 

be locally relevant, and usually some sort of negotiating or networks is that they can use a range of transmission rates 

decision-making functionality. A community of agents can flexibly, choosing that most appropriate for the service being 

then perform negotiation tasks amongst themselves to 65 delivered. 

decide a way forward on behalf of multiple entities in a Future service retailing might be offered across an archi- 

distributed system. tecture of the telecommunication information networking 
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architecture type. This brings together elements of the A service may have many users in different roles. For 

multi-service network and DPE technologies mentioned. An example, the end-user is the person who uses the service for 

example of such an architecture is that being defined by the its intended function, the service manager manages the 

UNA Consortium. Reference might be made to "Telecom- service, and the network provider provides and manages the 

munications Information Networking Architecture", 5 underlying resources required by a service. The notion of 

Oshisanwo A., Boyd T., Proc. 4th IEEE Conf. service in TINA-C applies to aU applications that are acces- 

Telecommunications, IEEE, London 1993. sible l ° user s» including management services. The service 

architecture contains a call model suitable for a wide range 

BRIEF DESCRIPTION OF THE DRAWINGS of service types. 

^ . ,. f . . .. .„ .10 Toe management architecture defines object types, and 

Embodiments of the present invention will now be , f • 4 . , 4 , • ,. 4 . 

, . , p i i -*u f . rules f° r tneu " usage, that can be used to design application 

described, by way of example only, with reference to the c * * • * i _i 

f . , J software to manage services, networks and computing sys- 

accompanying Figures in which: fams 

FIG. 1 shows information, computational and engineering ^ (known) QMG type DPE core provides for commu- 

representations of a system architecture for use in designing %$ nicatkms between objects> ^ d ic bindin yia a 

embodiments of the present invention; tradcr functk)n and prQvides notification xtvm t0 give 

FIG. 2 shows the structure of a DPE relevant to FIG. 1; management information (such as faults, performance and 

FIG. 3 shows a principally hardware view of platform for the like). It provides generic "Application Programming 

use in embodiments of the present invention; Interfaces" (APIs) and message passing facilities. All appli- 

FIG. 4 shows an overall multiple agent architecture and 20 cation software is assumed to run on a DPE. 
communication links between agents and supporting ele- Available documentation, in addition to the reference 

ments; given above, includes a set of deliverables, such as "0-0 

FIG. 5 shows an internal architecture for a user agent for Modelling and Design", by J Rumbaugh et al, published by 

use in the architecture of FIG. 4; Prentice Hall in 1991, "Overall Architecture" TINA-C 

c , a * 4 i u 25 Deliverable 1994 by M Chapman et al and "Guidelines for 

FIG. 6 shows a data set relevant to a user agent as shown ~ ~ c ( g j ^u- u . u , . (( ™ 

in FIG 5- Definition of Managed Objects , published in "The 

' Management of Telecommunications Networks" edited by R 

FIGS. 7 and 8 show protocols for user agents of a caller Smith et al md published by Ellis-Horwood in 1992. 

and a callee during call set-up; System Design Techniques 

FIG. 9 shows a high level system model for embodiments 30 Referring to FIG. 1, to enable system design according to 

of the present invention; a TINA-C architecture, three ODP viewpoints can be 

FIG. 10 shows an object model for the application selected, these being as follows: 
described as an embodiment of the present invention; 

FIGS. 11 and 12 show process steps involved in logging Information: a viewpoint on a system that focuses on the 
on and attempting to make a call using an embodiment of the 35 semantics of information and information processing 
present invention; and activities in the system. 

FIG. 13 shows a goal hierarchy for use in solutions Computational: a viewpoint on a system that focuses on the 
according to the prior art. distributable software objects and their interactions. 

Engineering: a viewpoint on a system that focuses on the 
DETAILED DESCRIPTION OF THE 40 deployment and distribution aspects of the system and on 

INVENTION the infrastructure to support distribution. 

As mentioned above, a suitable technical context for ^ . c *u * c a n* * a c a 

r ,u *• , ■ r For each of these, a set of modelling concepts are defined, 

embodiments or the present invention would be an infor- . , ... , r . c ' 

. u * * f(U , ac it. iL providmg a vocabulary that can be used to specify a system 

mation networking architecture of the type defined by the r , .° . , . ^ , r J 3 

• t * *r . ■ * . . 45 in the viewpoint addressed, 

lelecommumcations Information Networking Architecture « ■ f v. A «• i. • ■% 

^ mxT A ^ o , .... .. _, The information modelling concepts shown m FIG. la 

Consortium (TINA^C). Such an architecture is based on idfi ^ framework fo f information specifications, 

Open Distnbuted Processing (ODP principles of object describin ^ w g02 informa J n ^ m a 

orientation and distribution, applied to telecommunications °a t u a iL:„; t : ac . t u nt „«, aA _ . ^ 

, . • i . r . . . w A XT t system and the activities that are performed on the infor- 

y wt^T \ C0 T U T . 0 ?r ?M g ! m6 l n^ 50 mation - A" information specification describes the seman- 

7Zt°^P manag J a ", lnl f l & M " tM < IN > tics of the problem domain that the application software is 

concepts tor service management and control. u • a - a r r i • l i • 

& being designed lor. For example, in a banking scenario an 

In a TINA-C architecture, there are three sets of concepts, information model may contain objects such as account, 

a logical framework architecture, a service architecture, and debitf credit) aod ba i aace) and relationships such as debits 

a management architecture. 55 plus credits equals balance 

The logical framework architecture defines concepts and The fundamental concepts of information modelling are 
principles for the design of object-oriented software that objects, which are information bearing entities, object types 
operates in a distributed environment. Here a traditional 801, 802, that classify objects and define an object's char- 
layered computer architecture is defined, with computers acteristics in terms of attributes and operations that may be 
and computer networks at the bottom, a distributed process- eo performed on objects, and relationships 803 that define links 
ing environment (DPE) in the middle, and (object-oriented) between, and aggregations of, objects, 
application software on top. Within TINA-C the notation chosen for information 

The application software is itself subject to organisation specifications is the ISO/IEC and ITU-T recommended 
in TINA-C. The service architecture defines basic object GDMO (Guidelines for the Definition of Managed Objects) 
types, and rules for their usage that can be used to design 65 with GRM (General Relationship Model). GDMO is exten- 
application software that provides services. A service is sively used in the TMN community for information mod- 
defined as a meaningful set of capabilities provided to a user. elling and thus allows TINA-C to directly reuse this work. 
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Rumbaugh's OMT (Object Management Tool) notation of service. However, they may both be implemented by the 

(described in "Object-Oriented Modelling and Design", by same physical network. 

Rumbaugh et al, published by Prentice-Hall in 1991) is used DPE stubs are software modules linked with computa- 

for graphical representation of information specifications. tional objects which intercept interactions on objects, and 

The computational modelling concepts shown in FIG. lb s use the underlying kernel transport network 901 to establish 

provide the framework for computational specifications. A bindings and to transmit and receive invocation messages to 

computational specification describes distributed telecom- and from remote objects. In practice, an interface for an 

munications applications in terms of computational objects object is designed and compiled. This generates a stub which 

805 interacting with each other. Computational objects are will receive incoming messages to the object and select 

defined without any knowledge of where the computational 10 which operation is to be invoked by means of the interface, 

objects will eventually be deployed i.e. distribution is made DPE servers 809 provide infrastructure support. Two 

transparent. This allows for the specification of a software examples might be a trader and a notification server. A trader 

system that can tolerate the redeployment of software onto provides a run-time mechanism that allows objects to locate 

different nodes of a network without affecting the specifi- the interfaces of other objects. A notification server enables 

cation. The fundamental concepts of computational model- 15 objects to emit notifications (i.e. significant events that occur 

ling are objects 805 and interfaces 806, 807. Objects are the during the lifetime of an object) to other objects. Objects 

units of programming, and encapsulation. Objects interact wishing to receive notifications register at run-time with the 

with each other by the sending and receiving of information notification server. 

to and from interfaces. An object may provide many Referring to FIG. 3, the hardware view of a system in 
interfaces, either of the same or different types. There are 20 which embodiments of the present invention might be built 
two forms of interface that an object may offer or use: is based on a transport network 1100 which will carry for 
operational interface 806 and stream interface 807. An instance voice and data services, provided by service pro- 
operational interface 806 is one that has defined operations, viders to users. The users will be connected to the network 
that allow for functions of an offering (server) object 809 to by different pieces of customer premises equipment (CPE) 
be invoked by other (client) objects. An operation may have 25 1101, 1102. The various parties involved in offering and 
arguments and may return results. A stream interface 807 is carrying those services, such as the service retailer, service 
one without operations (i.e. there is no notion of input/output provider and network provider, are also connected at corn- 
parameters, requests, results, or notifications). The estab- putational nodes 810 to the transport network 1100. Intelli- 
lishment of a stream between stream interfaces 807 allows gent software agents, for instance a terminal agent 102 and 
for the passing of other structured information, such as video 30 a user agent 107, will sit on either the same or different ones 
or voice bit streams. of computational nodes 810 connected to the transport 

A notation which might be chosen for computational network 1100. 

specifications is TINA-C ODL (Object Definition As shown in FIG. 3, the terminal agent 102 and user agent 

Language), which is an enhancement of OMG IDL (Object 107 sit on the same computational node 810. These agents 

Management Group Interface Definition Language). 35 are provided with data of various types, including for 

TINA-C has extended OMG IDL to allow for the definition instance user profiles in a user profile store 1103 which 

of objects that have multiple interfaces and for the definition happens to share the computational node 810 with the user 

of stream interfaces. agent 107 and terminal agent 102. Other data stores avail - 

The engineering modelling concepts shown in FIG. lc able by means of the transport network 1100, as shown, 

provide the framework for engineering specifications. An 40 might for instance include a management information data 

engineering specification describes the deployment view of store 1105. The management information data store 1105 

a system in terms of which computational objects 805, 809 may provide global management information in respect of 

are placed on what computing node 810. It also defines the services. Each computational node 810 is provided with a 

infrastructure to allow objects to execute and communicate DPE kernel 811, and therefore a protocol stack for use 

with each other. 45 according to DPE principles. 

DPE and Hardware Context "Session" and "Access" Concepts 

Referring to FIG. 2, the infrastructure aspects of the TINA-C systems make use of "session" concepts and 

engineering model will define the Distributed Processing "access concepts. These are as follows. 

Environment (DPE). As mentioned above the DPE is an Session concepts define those objects and interfaces that 

infrastructure (of known type) that supports the interactions 50 are required to support the initiation of, interaction with, and 

of computational objects. The DPE shields applications termination of services. Although services by their nature 

programs from the heterogeneous and distributed nature of are different from each other, they all have a common 

the underlying environment, and provides the mechanism fundamental property in that they provide a context for 

that allows objects to interact without knowing the comput- relating activities. Such a context is termed a Session. As a 

ing nodes 810 they are on. The DPE defines four types of 55 generic definition, the term session represents a temporal 

entity: DPE kernel 811, kernel transport network 901, DPE period during which activities are carried out with the 

stubs, and DPE servers 809. purpose of achieving a goal. Three types of session have 

The DPE kernel defines a core set of communications, been identified: service session, user session, and commu- 

storage and processing capabilities (e.g., protocol stack). nications session. 

This core set is assumed to be present on each node. 60 A Service session is the single activation of a service. It 

The kernel transport network 901 is a communications relates the users of the service together so that they can 

network to which all DPE kernels are attached in order to interact with each other and share entities, such as docu- 

exchange messages to facilitate object interaction. It is ments or blackboards. A service session logically contains 

defined in order to logically separate the computing network the service logic. A service session is computationally rep- 

from a transport network which is used for the transmission 65 resented by a service session manager. A service session 

of voice and video. The logical separation recognises that manager offers two types of operational interfaces. The first 

the two networks may have different requirements on quality is a generic session control interface. This provides opcra- 
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tions that allow users to join and leave a service. For certain denning the TINA-C access model. An agent is this context 

services it may also offer operations to suspend and resume is a computational object, or collection of objects, that acts 

involvement in a service. The second type of interface will on behalf of another entity. 

provide service specific operations, and will be dictated by A user agent 107 represents and acts on behalf of a user, 

the capabilities offered by the service logic. 5 It receives requests from users to establish service sessions, 

The ability to suspend and resume involvement in a or to join existing service sessions, and creates or negotiates 

service is a desirable feature for some services. For example, wilh existing service sessions as appropriate. The creation of 

consider a multi-media conference that occurs over several a service session b y a user a S ent 107 can be subject to 

days. During the night, when the conference is not in use, it subscription and authentication checks. A user agent 107 

should be possible to release expensive communications 10 f 0 receives and process< * [ K ^f s t0 J™ a ™ I 8688 ™ 

resources. The service session can maintain state about the from SerV1C " ™™° nS themselves • ™» * * fo™ / 

c u *u j in-coming call processing where another user has created a 

conference, such as the users and resources involved. Main- ^„^ a JL™ .u- ♦ • n V 

f . . A . .... t . , service session and mvites the user to join in. User agents 

tenance of state and the ability to suspend and resume 107 ^ the subscribed xr/iass that J a user c f eate 

involvement would avoid the need for teanng down and list can be presented t0 the user when the user ' lo 0D 

recreating the service each day. 15 t0 ^ ^ agent 107, 

A User session maintains state about a user's activities A terminal agent 102 is responsible for representing a 

and the resources allocated for their involvement in a service terminal. It is responsible for obtaining the precise location 

session. Examples of state held in a user session include the of a terminal. Two examples are; the network access point a 

user's accumulated charge, suspension and resumption portable computer is attached to, and the cell in which a 

history, and service specific state such as the current page 20 mobile phone is currently located. 

being edited in a distributed document editing service, for In order to access a service, users must associate their user 

example. When a user joins a service session, a user session agents 107 with terminal agents 102. This is part of a logging 

is created. It is deleted when he leaves. The service session on process. A user may be simultaneously associated with 

maintains links to the user sessions and thus provides a manv terminals. For example, in a video conference a user 

group oriented view. 25 ma y be using both a workstation and a telephone. Similarly 

A Communication session is a service oriented abstraction a terminal may be simultaneously associated with many 

of connections in the transport network. A communication users » for example, when in a meeting all users associated 

session maintains state about the connections of a particular their user agents with the telephone in the meeting room, 

service session, such as the communication paths, end- User and terminal agents 107, 102 are computational 

points and quality of service characteristic. A communica- 30 objects that should have high reliability properties. These are 

tion session is required only when stream between compu- required so that the network software can rely on a fixed 

tational objects are required. Computationally a P°^ Dt f° r locating users and terminals in an environment 

communication session manager provides the features of a where both may be moving around, 

communication session. It provides a connection graph 1 . Agent Architecture 

interface of a service session to manipulate. A connection 35 This section describes the architecture of agents involved 

graph is an abstraction that defines concepts such as end- m embodiments of the present invention. It is important to 

points and lines. A service session expresses connectivity note that the application described in the following example 

requirements be adding, removing and linking end-points (s) only builds intelligence into the user agents, i.e. the 

and lines. A service session manager will request connec- negotiation process only occurs between the user agents, 

tivity between stream interfaces of computational objects. 40 Thus, while Terminal Agents and Network Agents exist, 

The communication session manager calls upon connection tnere k 00 intelligence in these agents for the purpose of the 

management objects to establish physical connections present description, 

between the network access points of the relevant computing 1-1 Inter- Agent Architecture 

node, and nodal services that allow for a network access Referring to FIG. 4, agents 405 are located on a number 

point to be connected to the software stream interface. 45 °f hosts 810. Each host 810 has a UNIX process running, 

Connection management components are not discussed fur- called an "office" 400. Communication between hosts 810 is 

ther in this specification. carried out through the "office" process 400. The commu- 

Auser can be simultaneously involved in multiple service nication is based on TCP/IP sockets, using a port (e.g. port 

sessions. A service session has one or more users associated 7000). Communication between agents 405 and an office 

with it, and for each associated user there will be a related 50 400 located on the same host 810 are performed through 

user session. A service session may have one or more "pipes". Information from the Terminal Agents is also 

communication sessions if the service involves stream com- communicated to User Interfaces 410 through the same 

munication. A communication session is related to exactly communication mechanism, 

one service session. 1 2 Intra-Agent Architecture 

The purpose of these separations is to decouple service 55 Referring to FIG. 5, the intelligence of the User Agent 107 
oriented activities from connection oriented activities. Many 15 comprised of five principal objects: Customer 500, Term- 
types of services may exist in a future network and not all Session 505, Session 510, Negotiator 515 and Evaluator 
will require the explicit establishment of connections 520 - Two other objects, io and parser 525,530, are required 
(streams). The service session is therefore a point of control f° r communication from other objects and agents, and 
for all service types, creating communication sessions when 60 ensuring messages are passed on to the appropriate object, 
necessary. The following sections give an overview of the functionality 

Access concepts define those objects and interfaces that of eaCQ object, 

support user and terminal access to services. Customer Object 500 

Users need to have flexible access to services, in terms of The customer object handles: 

the locations from which they access the service and the 65 (>) logging on and off 

types of terminal they use. User access is therefore distin- (ii) initial queries concerning the configuration informa- 

guished from terminal access. An agent concept is used in tion 
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(iii) initial request to accept a call from a caller (ii) there are no preferences expressed as to which of the 

TermSession Object 505 possibilities a user would prefer; 

A terminal session object is created by the caller when- (iii) a single goal hierarchy is required for all users. Some 

ever a request is made to logon at a terminal. The TermSes- users may not wish other users to know their user 

sion object 505 handles the initial request by the Caller to 5 policies; and 

make a call tce mfK j e l could not represent combinations of 

Session Object 510 achieving a call via other mediums of transmission. 

A Session object 510 is created whenever a new call is i n embodiments of the present invention, at least one or 

made. The following functionality is provided: m0 re of these limitations can be overcome. A feature can be 

(i) Receiving messages concerning the termination of 30 represented in terms of a high level goal. Taking the goal of 
calls either by the callee or from the network not wanting to be disturbed unless urgent, this can be 

(ii) Sending requests for user validation to the User Agent expressed in the form of an ordered set of lower level, 
Manager alternative goals: 

Negotiator Object 515 0 wanting all calls to go to a mailbox 

A negotiator object 515 is created upon creation of a 15 *0 t0 De delegated to some named person, 

session object 510 and succesful validation of a User Agent iii) or, if urgent, will take the call 

107 by the User Agent Manager. The negotiator object 515 High level goals can thus be mapped into sets of alter- 

handles which message operations to send between the native call configurations which can be ranked according to 

caller and callee's User Agent 107 when a call attempt is preference. This mapping can be hard coded or achieved 

made. 2Q through a set of rules which will dynamically assign pref- 

Evaluator Object 520 erence ratings based on a series of questions which guide the 

The Evaluator object 520 calculates the initial proposal USe A r t0 whicl ! goals they wish to achieve. 

and subsequent responses to a proposal when a call attempt M an e * a ^ Cal1 WaUm ? m a whlch CM . be 

is made represented as the more general goal of a user not wanting 

2 Knowled e Re resentation t0 m * SS m %? a ^ ca ^ s * 

r> c • * of^c ,1 25 These high level goals can be used to describe both 

Referring to FIGS. 3 and 6, the user agent 107 contains all incomi and out ; calls Some &rthcr ks are 

he current intelligence. It accesses stored information in the iven m me tabk below: 

User Profile and User Policies datastore 1103. The User 

Profile contains information on a user's id, password and 

their preferences while the User Policies datastore holds 30 

information on the strategies which should be deployed. High Level Goal 

The preferences may include information concerning \ ~ 

when calls can be set up at later times (i.e. dynamic Outgomg 

time-of-day routing). I don't want callees to know my phone number 

When a user logs on, they access the user agent 107 via 35 I want outgoing calls to complete now rather than later 

the User Agent Manager ("CustMan Object" in the Terminal 1 want to rcach the I* 150 " c 0110 " 11 ^ if possible rather than voicemail 

Agent). The user agent 107 accesses the user profile 600 for l ,™ nt . to 'T™ a ^ * ,f U IT* * T* 1 ' f thc ? u? C ' S ^ c is busy 

, j j ■ 1 ■ ( thls mi S nt bc an urgent call or because I am only available now) 

that user and displays it on screen. 1 wa nt caiiee to reserve a time to call me back if possible if their line is 

If a user logs off from a terminal, the mode will be busy 

changed either automatically or by the user. Otherwise, a 40 Incomip g Calls 

user may simply change modes to indicate they have tem- f A ^ A - ♦ u a ^ 

m 1 r i_- ■ i_ * n> I do not want to be disturbed unless tt is urgent 

poranly lelt a machine Without logging off. I do not want to take calls between times x and y 

2.1 Feature Representation I want to know who's calling me before I answer 

Referring to FIG. 13, in known agent-based systems such 1 want a11 incomin g calls to complete 

as that described by Griffeths & Velthuijsen (referenced 45 

above), a goal hierarchy 1300 can be used to represent the 2.2 User Configuration 

possible plans which can achieve the goals of all the agents A user's configuration describes how a user prefers their 

involved. calls (incoming and outgoing) to be handled. The user's 

In FIG. 13, one subscriber who has an unlisted number configuration defines, for both incoming and outgoing calls, 

proposes a call to another subscriber with calling number 50 a set of call configuration options. Each call configuration 

delivery (CND). As the subscriber with an unlisted number option within the set is represented by a set of attributes, 

does not want his or her number to be generally known, this together with their associated values, and a basic preference 

unlisted number (UN) feature is incompatible with the rating. Some of the attributes will be fixed, while others will 

calling number delivery feature. On receipt of this proposal, specify a range of values. In the latter case, a numerical 

CND sees that the proposal does not include the delivery of 55 indicator will be specified with one or more of the alternative 

the number and thus returns the previous proposal with values which indicates an amount to be decremented from 

calling-number-delivery added. UN receives this proposal the basic preference rating. Thus, each call configuration 

and decides that it is unacceptable. However, he is able to option of the set has a range of associated preference ratings, 

offer a counter-proposal, using his goal hierarchy, with the This is further discussed below. 

name delivery instead of the number delivery. This is 60 By defining a preference structure in relation to a set of 

acceptable to CND and thus returns notification of this call configurations, the user can give priority to one choice 

agreement. 0 f ca u configuration over another and thus determine a 

While, this represents a useful approach in terms of negotiation pattern for that user's agent, 

considering the user's behaviours, there are a number of It might be noted that the user agent 107 is persistent, 

limitations: 65 Decisions can therefore be made whether or not the user is 

(i) the representation is not rich enough to model more active. Also, preferences will usually bc set, or changed, 

complex constraints such as time; prior to call set-up, rather than during. 
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The following describes firstly the attributes for use in call basic preference rating might be 90, and for the "call taken" 

configurations, and then how a preference structure is option the basic preference rating might be 79. 

applied to those attributes, for a particular user. Looking at the "Mailbox" option 605, the top priority can 

2.21 Call Configuration Attributes be expressed by selecting the following values for the first 

The attributes describing a particular call configuration 5 three attributes and assigning the maximum basic preference 

are communicated between agents during a negotiation rating to this choice: 100. 
process in the form of proposals and counter-proposals. A 
call configuration is defined by the following attributes: 

(i) caller values: {person, recorded} ~ ~~ ~" 

'ii- u * j c u • it- ii -n Preference Value: 100 

ttns attribute defines who is calling, rhe caller may be an 10 Caller person 

actual person or it may be a recorded message in the case Caiiee mailbox 

when the callee is not available to receive calls or mail Callee-who direct (default value) 



messages at the present time. The caller may leave a 

recorded message which then gets sent to the callee at a Having defined these attributes, values can then be 

predetermined time or when the callee next logs on. 15 defiaed for the Qther atlributes . For each of these attribute 

(ii) callee: values: {person, queue, mailbox} values, there may also be user preferences. For example, the 
This attribute defines how the callee wishes to handle a user may prefer calls to be authorised and/or the medium to 

call. There are three possible values: either (i) the call will be voice rather than video. These preferences can be 

be taken by a person directly, (ii) the call can be put in a expressed by decrementing the basic preference rating for 

queue, or (iii) the call can be sent to the mailbox. 20 the "Mailbox" option by a relevant amount for each of the 

(iii) callee-who values: {direct, someone-else [X,Y„,]} alternatives it is preferred should not be accepted. That is, 
This attribute defines whether the callee will be the person each such alternative value is given a negative preference 

requested or whether the call will be taken by someone else. rating. A minimum preference rating for a set of call 

In this latter case, a parameter specifies a list of delegates. configurations providing one of the three options (ie the 

(iv) authorised values: {yes, no} 25 bottom end of the preference range for that option) can 
This attribute defines whether the call needs an authori- therefore be determined by summing all the possible nega- 

sation code. tive preference ratings which can occur within a single call 

(v) medium values: {voice, video, text} configuration and subtracting this from the basic preference 
This attribute defines which medium is being used to 30 ratin S for the option. 

transmit the call. The 'video' value includes voice. 0ne possible set of values are shown below for the 

(vi) schedule values: {now, caller [time], callee [time]} 'mailbox* option 605: 
This attribute defines whether the call is to be taken now 

or whether it will be taken later. In the latter case, it defines 

the responsibility for setting up the call (caller/callee) and a 35 Preference Range 100-92 

time parameter which specifies one of the following possi- Caller person: yes (0), recorded: no 

bilities: 'before tl\ 'after tl\ 'at tl/, 'asap\ Call" person: no; queue: no; mailbox: yes (0) 

(vii) caller info values: {none, name, number} S„ ^T^L* y* (0) 

This attribute represents what information the caller is Medium voice: yes (-3) | video: yes (-5) | text: yes (0) 

prepared to provide to the callee. It may take a subset of the 40 Schedule now: yes (0) | caller calls back: no | callee calls back: 

above values. no 

/ 11 ■ r 1 r . 1 Caller Lnfo Forename: present: yes (0); absent: no 

(viu) callee info values: {none, name, number} Surname: p ; sent: yes (0) / ahsenl: n0 

This attribute represents what information the callee is Company: present: no; absent: yes (0) 

prepared to accept from the Caller. It may take a subset of the C 3 ' 1 " ' mio Forename: present: yes (0); absent: no 

above values. 45 Surname: present: yes (-3); absent: yes (0), 

2.2.2 Call Configuration Options Ordered by Preference Company: present: no; absent: yes (0) 

Ranges 

It is possible to identify a "mode" of operation for a user. table above defines a set of proposed call configura- 

This is in practice a high level goal which predetermines tions f° r tne "Mailbox" option 605 (ie where the callee is 

some lower level goals and defines a context of operation 50 "mailbox"). The basic preference rating has been set at 100 

such as calls to be directed to a mailbox, or person to person because the user prefers this option most. There are three 

only. In practice, the mode can be selected, or determined, values with negative preference ratings, these being where 

by selecting values from the first two or three attributes in a the medium is "voice" or "video" and the callee surname is 

call configuration: caller, callee and callee-who. (The third present. The worst combination available available is 

attribute is only required if the second attribute uses the 55 medium being "video" (-5) and callee surname present (-3). 

value 'person'.) This provides a sum of -8. Hence the preference range for 

"Do Not Disturb" Mode this "Mailbox" option 605 is 100-92. 

In an example, shown in FIG. 6, a user's top priority An example of one proposed call configuration within this 

might be for all incoming calls to be diverted to the mailbox. option may be defined as: 

If this cannot be achieved, calls should be delegated to a 60 caller: person 

named person, and failing that the call might be taken if it callee: mailbox 

really is urgent. This high level goal, with the three options, calleeWho- direct 

could be expressed in the form of a 'do not disturb* mode . 

600. Each option for the "do not disturb" mode is given a authorised: absent 

basic preference rating, selected to reflect the order of 65 schedule: now 

preference. Hence the basic preference rating for "Mailbox" medium: text 

option 605 might be 100, for the "delegated" option 610 the caller forename: present 
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callee forename: present, surname: present which pro- 
duces a preference rating for this particular user of 97, 
based on the basic preference rating (100) minus the 
preference rating for the callee surname present (-3). 

This process is repeated by defining the set of call 5 
configurations, together with preference ratings, for the two 
other options for the mode "Do Not Disturb": delegated calls 
610 and receiving a call 615. The 'do not disturb' mode is 
then defined by the union of these three sets. 

As shown in FIG. 6, another available mode might be "No 10 
Calls" 620. This only differs at first sight, as shown, in the 
last option which replaces "Now-Take Call" with "Later" 
625. However, the preference ratings for the first and second 
options in this mode, "Now-Mailbox" 630 and "Now- 
Delegate" 635, may actually be very different in this mode 15 
from what they are for the same options in the "Do Not 
Disturb" mode 600. Indeed, as shown, the preference ranges 
are now 100-87 and 85-70 as shown. 

An analogous outgoing mode, 'completing a call', may 
represent the goals in decreasing preference of attempting to 20 
call a person directly, accepting a delegated call, or failing 
that leaving a message. 

The total set of call configurations for incoming and 
outgoing calls define a user's "negotiation space", which 
provides the framework to enable the user agents to make 25 
decisions about which goals they wish to achieve. 
2.2,3 Example 

In the following example, the caller, Mr Smithers wishes 
to call Mrs Richers. Mr Smithers prefers to call Mrs Richers 
directly rather than leave a message in her mailbox. He also 30 
prefers to setup the call now rather than set up the call later. 

Mrs Richers on the other hand, is in the 'do not disturb' 
mode. She does not want to be interrupted now. 

This information can be represented by the two sets of call 
configurations shown below. A negative number alongside 35 
an attribute value indicates that should that option be taken, 
the preference rating will be decreased by that amount. 

Where no multiple values are specified, this implies that 
only that value will be acceptable in that particular set. 

2.2.3.1 Caller's Ordered Set of Call Configuration Options 40 
(i.e. Mr Smithers'): 

Mode: Contact person now either person-to-person or 
leave mail message. 

Call Configuration Option a): Preference Range: 100-91 
Caller: person 45 
Callee: person 
who: direct 

authorisation: no/yes (-1) 

medium: voice 50 
schedule: now/caller sets up call later (-8) 
caller info: none 

Call Configuration Option b): Preference Range: 90-80 
Caller: person 
Callee: mailbox 
who: direct 

authorisation: no/yes (-1) 
medium: voice/text (-9) 
schedule: now 
caller info: none 

2.2.3.2 Callee's Ordered Set of Call Configuration Options 
(i.e. Mrs Richers*): 

Mode: Do not disturb 65 
Call Configuration Option a): Preference Range: 10O-90 
Caller: person/recorded (-1) 



55 



60 



Callee: mailbox 

Who: direct 

Authorisation: no 

Medium: voice/video/text (-3) 

Schedule: now 

Callee info: name/[ ] (-6) 

Call Configuration Option b): Preference Range: 90-80 
Caller: person/recorded (-1) 
Callee: person 

Who: someone-else [Fred] (-5),/someone-else [George] 

(-7), 
Authorisation: no 
Medium: voice/video 
Schedule: now 
Callee info: name/none (-2) 

Call Configuration Option c): Preference Range: 80-70 
Caller: person 
Callee: person 
Who: direct 

Authorisation: yes/no (-6) 

Medium: voice /video 

Schedule: caller set up call later 

Callee info: name/none (-4) 
2.2.4 User Profile 

A user's profile describes the mapping from the set of high 
level goals defined by the user to the call configurations. An 
example is given by FIG. 6. 
3. Negotiation 

On making a call, a user triggers their user agent. The user 
agent refers to the user's profile, generates a proposal and 
transmits it to the callee's user agent. The proposal will 
comprise one or more call configurations. 

On receipt of a proposal, a negotiation process is initiated. 
The callee's agent is required to accept the proposal, counter 
with a proposal of their own or reject the proposal. To do 
that, the callee's user agent will first review the proposal 
against their own modes, options and preferences to see if 
there is at least one acceptable call configuration in the 
proposal. If there isn't, the callee's user agent needs to 
generate a counter proposal, unless the incoming proposal 
was too far below the callee's agent's stored preferences. If 
the latter is true, then the callee's user agent may reject the 
incoming proposal and the connection will simply fail. If it 
isn't true, the callee's agent may send back a counter- 
proposal and the negotiation will continue. 

Each agent involved determines their response to a pro- 
posal or counter proposal in the negotiation process by 
taking into account their set of preferences within a given 
context. The aim is to select and put in place a call 
configuration which describes a mutually acceptable call 
handling scenario. That is, a call configuration which falls in 
the negotiation space of both agents. 

Referring to FIGS. 7 and 8, the negotiation process is now 
described in more detail. 

A proposal, or counter-proposal defines a particular call 
configuration. In order to communicate these proposals and 
counter-proposals between user's agents, a number of per- 
formatives are introduced. These performatives arc given 
below together with an informal description: 
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Performative Description 

accept- if This offer describes a set of proposals which are acceptable. ^ 

It does not however exclude other possibilities which are 

not specified in this offer, 
fail-if-not This offer describes a set of proposals which if the other 

user does not accept, forces a failure and the end of the 

negotiation process. 

acceptance the caller/callee user's agent have agreed to a proposal or 10 
counter proposal 

resolution the callee has agreed to the proposal put forward by the 
caller 

failure the caller/callee 's User Agent or the caller/callee cannot 

agree to any proposals and so the negotiation ends 

succeed the caller and callee's User Agent have already agreed to a 15 
set of proposals and now the caller/callee chooses which 
particular proposal from the set of proposals offered. It is 
possible that a caller will send a set of proposals which is 
a singleton. In this case, the callee can subsequently receive 
a resolution. 



3.1 Protocol 

Referring to FIGS. 7 and 8, the protocol is defined using 
a state transition diagram to show the sequence of permitted 
messages for both the caller and callee. For the purpose of 
these diagrams, an exclamation mark (!) indicates 'send* to 25 
other user and a question mark(?) indicates 'receive* from 
other user. 

A further constraint is also placed on the protocol such 
that if a configuration has been proposed using an ' accept-if ' 
performative, and it has been refused by the other parties 30 
involved in the negotiation, it is not possible to repeat this 
configuration. 

Negotiation is based on: 

the knowledge representation used to express the goals 
and preferences between goals 35 

the strategy used to determine the type of proposal to send 
and how to evaluate a proposal received from another 
user's agent. 

The knowledge representation has been discussed above. 
It is the use of goals, expressed as call configuration 
attributes, together with the associated preference ratings. 40 
Interagent communication is then carried out, using knowl- 
edge representations, according to a protocol of the follow- 
ing type. 

FIGS. 7 and 8 show state transition diagrams for a caller 
and a callee respectively. They describe what message 45 
operations are possible given the state (initial/proposed/ 
confirmed/succeed) 705, 710, 715, 725 and which party 
(caller/callee) has sent the message. A number of possible 
events (proposal, counter, succeed (proposals), acceptance, 
resolution and failure) 720 can occur at each given state. 50 

The object structure describes the content of the 
negotiation, which in the context of this application, is the 
proposal describing the combination of call characteristics to 
be performed. 

3.2 Decision Process 55 
This section describes: 

how an individual agent makes a decision as to which 

message operation to send, and 
how an agent decides upon the content of the proposal or 

counter proposal if one is offered. 60 
3.2.1 Environmental Parameters 

When a request is made by a caller to make a call, some 
static information is used: 

caller (Name) — the name of the caller 

delegated (Via) — if calls have been delegated to someone 65 

else, the 'Via' field is filled in with the name of the 

callee who decided to delegate their calls. 
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callclass(Class) — the class defines whether the call is 

business or personal. 
In addition, proposals must also take account of a number 
of attributes which define the environment: 

(i) mode — determines the context in which the user 
wishes to make or receive calls, e.g. 'do not disturb*, 
'contact callee directly', etc. 

(ii) state of a session — free, busy 

(iii) location — determined by the Terminal Agent which 
can identify the user's host machine which the user is 
logged into 

(iv) intentions — commitments a user has made together 
with their associated priority 

(v) current negotiations — other negotiations the user is 
involved in, but which have not yet come to a success- 
ful conclusion 

These attributes determine the set of proposals from 
which the initial proposal will be chosen. 
3.2.2. Generating Initial Proposal 

As mentioned in the previous section, the environmental 
parameters constrain the set of possible proposals from 
which any proposal can be selected. The initial proposal will 
be generated by selecting the proposal from this set with the 
highest preference rating. 

3.2.3 Generating Counter Offers 

The process given below provides an overview of how a 
user agent should respond to an offer: 

1. Find a possible proposal using the next highest pref- 
erence from profile. This preference will take into 
account the current state of the user, i.e. free or busy, 
together with previous proposals which have failed. If 
a preference can be found, go to step 2, else, send a 
message back to the other user agent indicating a 
failure together with the reason. 

2. Check the possible proposal against intentions. If this 
passes, go to step 3, else go back to step 1 with a 
message indicating a failure together with the reason. 

3. Check the possible proposal against current negotia- 
tions. If this passes, then send proposal back to other 
user agent indicating the counter proposal together with 
the reason why counter proposal is being sent. If this 
fails, then go back to step 1 with a message indicating 
a failure together with the reason. 

Two types of counter offers can be made: 
'Accept if* 

This offer describes a set of proposals which are accept- 
able and have not previously been sent. It does not however 
exclude other possibilities which are not specified in this 
offer. 

'Fail if not' 

This offer describes a set of proposals which if the other 
does not accept, forces the end of the negotiation process. 
This offer reduces the negotiation space. 

3.2.4 Strategies 
General 

A number of strategies can be generated using the form of 
the counter proposals discussed above. One such strategy is 
shown below: 
1. If 

receive Accept If (proposed) and 

f (proposal, myPreferences)«accept then 

send 'accept(proposal)' 

The function "f(proposal, myPreferences)" determines 
whether the proposal is acceptable or not by examining the 
list of proposals. 
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if a) P/ ^<accept-if, C,- «>, U[c miM ]=G %*V[c mmx l NS ( . 

the size of the list of possible proposals>size list w-NS^ ^.^C,- ^ if NS,- t ^-1°^, ^.^0 and len(NS t - 

then -)=D, x^i 

if b) py^fail-if-not, ^ ^> and C y - tt -NS t „«NS, ^ if 

the pref(proposal)>pref_^, (your threshold value) 5 j* 11 ' ^^t^"*" 1101 * ""^ ^ 

then t , n a) p y ^ucceed, C,'„>, U[c Wi -J=G %*U[ W ], if (C, tt 

accept (proposal) ^ c ^ U[miD (C y ^JJSA %*U[c ma J, or length 

else (NS. ^SQ) and NS i( ^HC,- «_^0 

counter with your best proposal from current negotia- 10 iii) If p ( -j x _ 1 o<fail-if-not ) ' C y> then we have two sub- 

tion space cases: 

else a) If C^jONS^ £v _ 3 =0, then p y>: «<failure> 

accept(proposal) b) If Cy^nNS,' ^0 and len(NS,. J^D, x^l, where 

2. If NS^^INS.^nq^then 

receive a proposal which is unacceptable (i.e. there is no 15 p Aw -<accept-if, c /, o>> U[c min ]~G %*U[c mfl J, Q 

intersection between what has been proposed and the « c Cy, «-i> 
set of acceptable proposals based on your preferences), 

then The parameters G, D and A can be varied to provide a 

send 'Fail If Not(whole set of proposals)' S reater or lesser de 8 ree of cooperation, 

gjgg 20 There are two important aspects of the strategy set out 

J(A . ,£ nf c r x above, these being the "Accept If * and "Fail If Not" mecha- 

send 'Accept If (top x % of your preferences) • r» * ♦? *u \i .u *■ r 

~ r. . f . v £ , ' ■»! * j * i „ msms. Between them, they reduce the negotiation space for 

Hie first step in the strategy will tend to make call . • i *• i l * t. r j * 

fi , • , . , ,Z c , the user agents in a relatively short number of rounds of 

configurations lower down the preference order more c c j r« . *«, 

° U1 . F . negotiation, for instance four or five rounds. The "Accept If 

acceptable as the negotiation process continues. , A t . *• r.u j- 

The parameters size oref x can all be varied 25 P ro P osal reduces the negotiation space of the sending agent 

me Parameters $i7£ propiis „ pret flC x can all be varied since tQOse configuralions cannot be resent> « Fail If 

givuig different degrees of co-operativeness. KT i v ■* *u *■ r u iL 

a . i . . * , r « . , , . Not proposal limits the negotiation space for both agents to 

A mathematical expression defining a strategy* as fol- what ; s Stained in mat proposal. 

lows. The strategy defines the reasoning used to evaluate the ™ *• *• ■ il* j - * n . 

e }\ ■ . The wav a negotiation might proceed is that a first agent 

. . . 30 selects a proposal from its top six preferred call configura- 

lnitial proposal to offer t j ons A second agent looks at its own negotiation space and 

counter-proposal from the other user's agent finds the proposal doesn't even meet its lowest criteria, ie the 

response to be made to the other user's counter-proposal bottom of its preference range. The second agent therefore 

Let the negotiation space for user,- at time i x be defined by sends its whole negotiation space as a "Fail If Not" proposal. 

NS, ^ where NS, „ is an ordered set of call configurations 35 The first a g ent selects from the "Fail If Not" proposal and 

{c a ,' c 2 , . . . ,c K J such that U(c i )<U(c( I+1 ), where U(c ( ) sends an "Accept If proposal. For instance, the first agent 

represents the preference of c,. Let C £ ^ and C />; represent mav nave found on review that only six call configurations 

the set of proposals and counter-proposals being offered by fr° m tne "Fail If Not" proposal fall in its preference range, 

user,- and user y , at time t^, respectively. We define a number The second agent sends back the best one of the call 

of parameters, which affect a user's degree of cooperation 40 configurations and the negotiation succeeds and is resolved. 

(i) Let G be such that C it ={c mini . . . , c }, such that T^ tv P e of negotiation strategy clearly has application to 
c^ +1 , x=min, . . . ,max-l, where U[c~J=G %*U negotiation procedures other than simply those used in 
[c„„]. We can think of G as representing the generosity communications, in call setup, and is independently inven- 
of the user and dictates the lowest preference value to tive in the context of software agents negotiating to select a 
offer in a set of proposals 45 mutua lty acceptable solution from a negotiation space which 

(ii) Let D be such that if a set of call configurations, C com P rises a ran S e °f °P*«» which can each be broken up 

are offered in a counter-proposal, it will be m !° ^-^ns and preferentially. For instance, 

accepted at time t, if length (NS, J^D, and NS, a , ihls J 0 " [d be . the case where a g™ts are negotiating to 

0 C y tt ^0. The value D represents a user's desper- estabhsh a P ncm § stT ^ over a ^>namodity with multiple 

atenessto agree to a proposal. 50 com P°n e nts where the components can be mixed and 

t * a u * * u iL * „ L . r ii matched to get an optimum combination. This applies in the 

(m) Ut A be a constant such that the set of ca 1 lravel ind ^ a oduct (oy ^ faas 

configurations, C, will be offered at time t x such that: J h as lra V vel modej acconimodatio n 

U[min(C y . *_ a )]£A %*U[c milx ) and C, tx £Cj u . lt and timing. . 

• h 1 55 4. Connection Setup in the TINA-C Environment 

where C y ^ was the counter-proposal offered by agent j at The following describes the setting up of a service session 

time t^. This parameter defines the level of acceptability of in a TINA-C environment, including the use of user agents 

a proposal from the other user. to implement an embodiment of the present invention to 

The strategy for user, at stage t^, x^O, can then be select and put in place a mutually acceptable configuration 

formulated as a set of rules defining the proposal, p t cc , 60 for the service session. 

offered at time, t^. We have three main cases: The application uses the TINA-C framework as a basis for 

determining individual agent roles and the sequence of 

(0 P;,/o= <a ccept if, C t - l0 > where U[c m/M ]=G %*U[c m J, Q interactions between each of the agents in order to establish 

^{c^, . • - , c^}, len(NS I( ^^D, and NS,- ri -NS,- f fl \C,' a service session. 

*o 65 (It should be noted that, by adopting the TINA ' session' 

(ii) If py, to _ 1 =<accept-if, C y tx _ 1 >, Vx, x>0, then we have the concept, it is possible to avoid the need to represent some 

following sub-cases: features. An example of this is a feature called 'Call 
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Waiting', which enables users to switch between two calls. (vi) act-proposal, proposal-Proposal, session -Session Id, 

This feature does not exist as such in the TINA system, since agent=Agent 

a user can receive any number of calls simultaneously. Every This message emanates from the Caller's User Agent via 

time an incoming call is accepted, a new 'call* window the negotiator object requesting the Callee's User Agent to 

appears on the terminal screen, which is associated with a 5 accept an initial proposal 

unique session identifier) 4.2.1.2 TermSession Object 1000 

Referring to FIG. 9, a system model gives a high level Attributes 

view of the system. The attributes for the TermSession object 1000 are: 

The User Agent 107 contains the intelligence to negotiate terminal Terminal Agent 

on behalf of Users to set up a call. ao , M „ c , 

mi i-p | i 4 L , . , . . # . iL location — name of the station 

1 tie Terminal Agent 102 holds information on the Creation method 

resources available and location of a station. A ™ „ . . . , - nAn . , , . u 

KT . . A t t . . . . j t_ • i A TermSession object 1000 is created usmg the call: 

Hie Network Agent U0 controls the logical and physical /aaa\ 

connections between the locations of the users involved in create(Agent, Address) 

ca jj s 15 where the following parameters are used: 

The Application 950 represents the particular program 0) Agent — Customer 

chosen to perform a call. This may be for instance a simple (ii) Address — location of the Terminal Agent 

voice call or a multi -media conference call. Speech Act Messages 

The User Interface 410 allows the user to make and The TermSession object 1000 responds to the following 

receive calls, access and change their user configurations. 20 speech act messages: 

4.1 Object Model ^ act-request, nature-makecall, callee-Callee, 
FIG. 10 shows object models for the principal objects of proposal=Password, address-Address, agent=Agent 

a user agent 107 and a terminal agent 102. Descriptions of message emanates from the User Interface via the 

the objects are given below. Terminal Agent to request to make a call. 

4.2 Object Description 25 4.2.1. 3 Session Object 1010 
(It should be noted that messages of known type which Attributes 

simply instruct an object or agent to perform a task are not The attributes for the Session object 1010 are: 

set out below. Only "speech act messages" arc detailed. ■ •** i 1 .t • 1 1 . c j i. iL 

™ u . ■ r x initial proposal — the initial proposal put forward by the 

Inese have a semantic nature, e.g. to inform or request.) caller 

4.2.1 User Agent 30 

4.2.1.1 Customer Object 1005 olher agent— the other agent involved in the call setup 

Attributes session id — a unique identifier (Caller User Agent, Id) 

name^customer's name Creation method 

passwd— password A Session ob j ect 1010 is created using the following call: 

Creation method 35 Create(Agent, Proposal, Session id) 

A customer object is created using the call: 0n creating a session, the following parameters are used: 

Create(Cust) (i) Agent — the other User Agent involved in the call, 

where the following parameters are used: (ii) Proposal — the initial proposal 

(i) Cust— Customer (iii) Sessionld— session identifier 

Speech Act Messages Speech Act Messages 

The customer object respond to the following speech act The Session methods respond to the following speech act 

messages: messages: 

(I) act-inform, nature-logon, address-Address, (j) act-inform, nature-userquery, rcsponsc=ok, user- 

password-Password, agent-Agent 45 Agent 

This message emanates from the User Interface via the A query response from the User Agent Manager to inform 

Terminal Agent informing the customer object that the user the User Agent that the User Agent (Agent) exists, 

is logging on. 4 . - 

. r , rr . , , ( u ) act- in form, nature-userquery, response-notok, user- 

(n) act=inform, nature=logoff, address-Address, agent* Agent 

Agent so A query response from the User Agent Manager to inform 

This message emanates from the User Interface via the the User ^ ent that the User A t does not exist 

Terminal Agent informing the customer object that the user / .... t . - 4 ° r . 0 . TJ 

is logging off ( m ) act ° inf orm, nature-connectfail, session-Sessionld 

nt • e 1 jj AJJ A message from the network to inform the User Agent that 

(111) act=inform, nature-logoff, address- Address, obi- # . „ u_ r , & 

v ' t . ' . & , _ , tne connection has failed. 

cust, customer- Customer, password-Password 55 

This message emanates from the User Interface via the ( 1V > act=mform . nature-connectend, session-Sessionld 

Terminal Agent informing about the password A messa g e from the network to inform the User Agent that 

(iv) act-request, nature =config, address- Address, agent= ^ con °f cti °D *** been terminated. 
Agent 4.2.1.4 Negotiator Object 1020 

This message emanates from the User Interface via the 60 ^ tr ^ ut ? l f r , XT . , . + Mn 

Terminal Agent, requesting the User Agent's configuration ^ atlnbutes for tDe Negotiator object 1020 are: 

information state — tDe current state (initial, proposed, confirm) 

(v) act-inform, nature-config, config-Config, address- direct— who is controlling the negotiation (send implies 
Address, agent- Agent control, receive implies someone else has proposed) 

This message emanates from the User Interface via the 65 proposals— a list of proposals seen so far, with the latest 

Terminal Agent informing the User Agent of a change in the proposal at the beginning of the list. 

Configuration information. othcrneg — the other user agent involved in the session 
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session — the joint negotiation Id generated by the con- 
troller 
Creation method 

The Negotiator object 1020 is created using the call: 
create(Agent, ProposalParameter, Sessionld, Direct) 
where the following attributes are used: 

(i) Agent — the other User Agent involved in the call 

(ii) ProposalParameter — the proposal made as part of the 
call 

(iii) Sessionld — the Sessionld created by the caller's User 
Agent 

(iv) Direct — who is controlling the negotiation (send 
implies control, receive implies someone else has 
proposed) 

Speech Act Messages 

The Negotiator object 1020 responds to the following 

speech act messages: 

(I) act=acceptance, session=SessionId, agent«OtherAgent 
This message emanates from the other agent's negotiator 

object requesting acceptance for a call setup. 

(ii) act=counter, session=SessionId, proposal** 
OtherProposal, agent-Other Agent 

This message emanates from the other agent's negotiator 
object informing the agent of a counter proposal. 

(iii) act=failure, session=SessionId, agent=OtherAgent 
This message emanates from the other agent's negotiator 

object informing the agent that the negotiation has termi- 
nated unsuccessfully 

(iv) act=resolution, session=SessionId, agent= 
OtherAgent 

This message emanates from the other agent's negotiator 
object informing the agent that the negotiation has termi- 
nated with a successful conclusion. 
4.2.1.5 Evaluator Object 1015 

Attributes 

There are no attributes for the Evaluator object 1015. 
Creation method 

The Evaluator object 1015 does not have to be created. 
Speech Act Messages 

There are no speech acts applicable to this object. 
4.2.2 Terminal Agent 
4.2.2.1 io_listen Object 1025 

Attributes 

The attributes of this object are: 
socket — server socket 
port — socket 

loctemplate — address name 
Creation method 

The io__listen object is created using the call: 

create(port) 
where port refers to a socket 

Speech Act Messages 

There are no speech act messages. 
4.22.2 io_port Object 1030 

Attributes 

The attributes of the io_port object are: 
socket — socket 
location — location name 
customer— customer name 
program — application (rtgui) 
agent — terminal agent name 
Creation method 

The io_port object is created using the following call: 
create(socket, Template) 



where the attributes are: 
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(i) socket — socket 

(ii) Template — Template name containing the host and 
5 port number 

Speech Act Messages 

The io_port object responds to the following messages: 

(i) act=inform, program-Program, host=Host 

A message from the User Interface to inform the Terminal 
io Agent about the application and host. 

(ii) act = inform, nature«logon, customer=Cust 

A message from the User Interface to inform the Terminal 
Agent about logging on. 

(iii) act«inform, nature=logoff, customer»Cust 
A message from the User Interface to inform the Terminal 

Agent about logging off. 

(iv) act=request, nature=config, customer=Cust 
A message from the User Interface to request the Terminal 

Agent for the configuration information. 

(v) act»inform, nature=config, config=Con, customer= 
Cust 

A message from the User Interface to inform the Terminal 
Agent about changes to the configuration information. 

(vi) act=inform, nature=makeCall, callee=Callee, 
mymode=Mode, preferences«preferences 

A message from the User Interface to inform the Terminal 
Agent about a make call. 

(vii) act=inform, nature=logresponse, address- 
30 Cust:Program@Location, password=Password 

A message from the User Agent via the Customer object 
to inform the Terminal Agent about a response to a logon. 

(viii) act=inform, nature=nosuchcust, address* 
Cust: Pro gram@Location 

35 A message from the User Agent via the Customer object 
to inform the Terminal Agent about a response to a logon and 
the User Agent does not exist. 

(ix) actoreply, config = Config, address = 
Cust: Pro gram@Location 

A message from the User Agent via the Customer object 
to inform the Terminal Agent about its configuration infor- 
mation 

4.2.2.3 User Agent Manager (Cust Man) Object 1035 
Attributes 

The attributes for the custman object are: 

functor — function of the agent (i.e. user agent) 
Creation method 

There are no parameters called to the create method: 
50 Speech Act Messages 

The custman object responds to the following speech act 
messages: 

(I) act«inform, nature=logon, address^Address, 
passwordoPassword, agent«Agent 
55 This message emanates from the Terminal Agent request- 
ing a logon. 

(ii) act«request, nature -userqucry, user=User, agent= 
Agent 

6Q This message emanates from the User Agent requesting a 
query of the existence of the agent (User). 
5. Scenarios 

Referring to FIGS. 11 and 12, the following process steps 
apply during log on by a user and a call attempt by a user. 
65 It will be seen that the numbers given below to the process 
steps arc repeated in FIGS. 11 and 12 to indicate which 
entities are involved in each process step. 
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5.1 User Logging On tinued until the Caller's User Agent decides to accept or 
Process reject the proposal. 

The User opens the run lime application. If the response is to accept the proposal, the CaUee's User 

1,2. A 'login window* is displayed once the User Interface Agent will send a message to the User Interface via the 

has registered a connection with the Terminal Agent 5 Terminal Agent to prompt the Callee to accept the call. If the 

3. The User enters his/her userld and password. A mes- Callee decides to accept the call, a message is sent back to 
sage is sent to the Terminal Agent to request logging on, the Terminal Agent to accept the call and this results in a 
together with the userld and password to the Terminal 'resolution' message being sent back to the Caller's User 
Agent. Agent. 

4. On receipt of this request, the Terminal Agent passes on If the response is to reject the proposal, both the Caller 
the request to the User Agent Manager. and Callee's User Agent will inform their respective users 

5. The User Agent Manager sends this message on to the that the call cannot be made and the negotiation will end. 
relevant User Agent via its customer object. Th e following steps have made some assumptions con- 

6. The Customer object creates a Termsession object, cerning what decisions are made. 

identified by the Terminal Agent which sent the message and 14> ^ CalIer > s Usef A t ^ the negotiator objecl 

the name of the station being used. « ^ a m back CaUee , s User & ^ eQt J ^ 

7. Rie Caller s User Agent via the customer object negotiator 

determines the validity of the user. If the password is correct, Tr ^ ' ^ « t u * . • • • „ . 

a message is sent to the Terminal Agent. ^ ™ e S alIee s "f" A S ent via lts negotiator calls the 

8. On receipt of a 'logresponse' message, the Terminal cva ^ a l? r ob J e t ct t0 calculate a response. 

Agent sends a message back to the originating User Inter- 20 16, ^ evaluator decides to accept the counter offer. The 

face located on the identified station. negotiator object sends a message to the Terminal Agent to 

At this point, the main application window is displayed, P Tom V l the Callee t0 acce P l the calL 

enabling users to make or receive calls. 17 ' 18 - ^ Ca]lee via the User Interface receives the 

5.2 User Attempting To Make A Call message and sends a message back to the Terminal Agent to 
Process 25 acce P t the call> 

1. On selecting the 'make call' button from the User 19 ' ^ Terminal Agent receives the confirmation from 
Interface, a message is sent to the Terminal Agent, contain- the CaUee ^ d ^ nds a m essage back to the Callee 's User 
ing the proposal, calleelD, mode, preferences and customer. via lts negotiator. 

2. On receipt of the message, the caller's Terminal Agent 20 ' ^ negotiator sends a message back to the Caller's 
sends a message containing the calleelD, current location, 30 User via lts negotiator ob j ect informing the User 
situation and proposal to the caller's User Agent via the A S ent that the cal1 P ro POsal has been agreed. 
TerminalSession object. (The preferences are not used at this At tms P omt the ne S otiator ob J ecl a »ks the Session object 
point. This only defines who is being called and the mode t0 xnd a messa g e t0 the network to proceed with the 
which has been selected— it is not until Step 7 that the connection and to prompt the Caller that the call setup has 
preferences based on the mode and other factors such as 35 Deen 

current state, are used to generate a proposal). 11 mi S nt be noted that though the "callee" will usually be 

3. On receipt of this message, the Terminal Session object a P erson ' i{ could ako be inanimate. For instance, if a user 
creates a new Session object. 15 not currently logged on, the callee will be a mailbox. 

4. If the Sessionld is empty, then a new Session identifier What b claimed is: 

is created using the ordered pair, (Caller's User Agent, Id). 40 1 A method of establishing a connection over a commu- 

The Caller's User Agent will then send a message to the nications network, for service provision between first and 

User Agent Manager to query the validity of the Callee. 500011(1 users of thc network, there being provided respective 

If the Sessionld already exists, then the user is responding connection set-up means for said users, which method 

to a request to join in an existing session. (see Step ) and the comprises: 

Sessionld will be taken from the existing session. 45 0 storin g f° r each of said users data defining at least one 

5. On receipt of this message, the User Agent Manager connection configuration, said connection configura- 
validates the Callee and sends a message back to the Caller's uon comprising at least one operation of the commu- 
User Agent via the Session object with the appropriate nications network in combination with an operation to 
response. be implemented at least in part by functionality of the 

6. On receipt of a successful response, the Session object 50 connection set-up means; 

creates a negotiator object, identified by the Sessionld. ") storing in respect of data defining a connection con- 

7. On creation of the negotiator object, the negotiator figuration for the second user, data defining at least one 
requests the evaluator to generate an initial proposal. alternative connection configuration; and 

8. The negotiator object sends the proposal together with iii) storing in respect of said data defining a connection 
the Sessionld to the Callee' s User Agent via the customer 55 configuration for the second user, and in respect of the 
object. data defining the or each of its alternative connection 

9. On receipt of this message, the Callee's User Agent via configuration(s), a respective priority indicator; 

the Customer object creates a Session object using the the method further comprising a negotiation process for the 

existing Sessionld. establishment of a connection by means of: 

10. The Session object creates a Negotiator object for the 60 iv) transmitting data defining a proposed connection con- 
Callee's User Agent using the existing Sessionld. figuration from the connection set-up means for the first 

11. The negotiator object asks the evaluator object to user to the connection set up means for the second user, 
calculate a response to the initial proposal. said proposed connection configuration comprising at 

12. A message is sent back to the Caller's User Agent via least one of an operation of the communications net- 
the Negotiator object with the appropriate response, 65 work and an operation to be implemented at least in 

13. On receipt of this message, the Negotiator object part by functionality of the connection set-up means for 
requests thc evaluator to calculate a response. This is con- the first user; 



12/30/2003, EAST Version: 1.4.1 



US 6,611,501 Bl 



29 



30 



v) reviewing the data defining the proposed configuration 
at the connection set-up means for the second user by 
accessing the data defining configurations and the 
respective priority indicators stored in respect of the 
second user; and 5 

vi) selecting and transmitting a response to the connection 
set-up means for the first user, the response being 
determined at least in part by the result of the review 
step v) above, and selected from acceptance or rejection 

of the proposed connection configuration, or compris- 10 
ing data defining a counter-proposed connection 
configuration, without having access to the stored data 
defining at least one connection configuration in respect 
of the first user. 

2. A method according to claim 1 wherein the data 15 
defining an operation to be performed at least in part by the 
connection setup means comprises time data and, in the 
event that the response is acceptance of a connection con- 
figuration comprising time data, the connection setup means 
subsequently attempts to set up a connection in accordance 2Q 
with said time data. 

3. A method according to claim 2 wherein said time data 
comprises a time of day and the connection setup means 
subsequently attempts to establish connection at that time of 

da y- . 25 

4. A method according to claim 2 wherein said time data 
comprises a time interval and the connection set up means 
subsequently attempts to establish connection after said time 
interval has passed. 

5. A method according to claim 1 wherein, in the event 30 
that the response comprises data defining a counter- 
proposed connection configuration, the negotiation process 
further comprises: 

vii) reviewing the data defining a counter-proposed con- 
nection configuration at the connection setup means for 35 
the first user by accessing the data defining configura- 
tions and respective priority indicators stored in respect 

of the first user; and 

viii) selecting and transmitting a response to the connec- 
tion setup means for the second user, the response being 40 
determined at least in part by the result of the review 
step vii) above, and selected from acceptance or rejec- 
tion of the counter-proposed connection configuration, 

or comprising data defining a further counter-proposed 
connection configuration. 45 

6. A method according to claim 5 wherein steps v) through 
viii) are carried out, and repeated if necessary, until a 
transmitted response is acceptance or rejection of a proposal. 

7. A method according to claim 6 which further comprises 
the step of logging, by the connection setup means for each 50 
user and at least for the duration of a single negotiation 
process, received connection configuration proposals, any 
subsequent proposal transmitted by either connection set up 
means excluding proposals previously transmitted by cither 
connection setup means. 55 

8. A method according to claim 1 which further comprises 
the step of storing, for each of said users, any current data 
relevant to connection setup for that user, in addition to data 
defining connection configurations, and the negotiation pro- 
cess further comprises the step of reviewing the additional 60 
data prior to transmission of data defining a proposed or 
counter-proposed connection configuration, and modifying 
the data defining a proposed or counter-proposed connection 
configuration accordingly. 

9. A method according to claim 8 wherein the additional 65 
data comprises one or more of the following: 

a) connection mode data; 



b) location data for the relevant user with respect to the 
network; 

c) commitment data, indicating commitments previously 
made by the relevant user; and 

d) concurrent negotiation process data for the relevant 
user. 

10. A method according to claim 6 wherein the data 
defining each proposed or counter-proposed connection con- 
figuration transmitted from a connection setup means is 
selected for transmission in accordance with a progression 
from proposals with a high priority indicator towards pro- 
posals with a relatively lower priority indicator, for the 
relevant user. 

11. A method according to claim 1 wherein each connec- 
tion setup means can be provided for a plurality of users and 
wherein the method can be carried out concurrently by a 
connection setup means for more than one user. 

12. A method according to claim 1, wherein each con- 
nection configuration comprises one or more features pro- 
viding a component of a communications service, the fea- 
tures being selected from a set of features at least two of 
which are mutually incompatible. 

13. An apparatus for use in establishing a communications 
connection between a first access point and at least one 
further access point of a communications network, the 
apparatus comprising connection set-up means associated 
with said first access point, the apparatus further comprising: 

an interface to the communications network for activating 
network operations available at said first access point; 
a data store for storing data defining at least one connec- 
tion configuration and an associated priority indicator 
in respect of said first access point, said connection 
configuration comprising at least one operation of the 
communications network in combination with an 
operation to be implemented at least in part by func- 
tionality of said connection set-up means; 
wherein said connection set-up means comprise: 

means to implement a negotiation process, in 
co-operation with connection set-up means associ- 
ated with said at least one further access point, to 
agree a set of operations of the communications 
network and of said connection set-up means for 
implementing said communications connection; and 
means to implement said agreed set of operations in 

respect of said first access point; 
said negotiation process comprising the steps of: 

(i) receiving data defining a proposed connection 
configuration; 

(ii) reviewing the received data in comparison with 
connection configuration data and priority indica- 
tors stored in the data store; and 

(in) selecting and transmitting a response to said 
received proposal, the response being determined 
at least in part by the result of the review step (ii) 
and selected from acceptance or rejection of the 
proposed connection configuration or comprising 
data defining a counter-proposed connection con- 
figuration. 

14. Apparatus according to claim 13 wherein the data 
defining an operation to be performed at least in part by the 
respective connection setup means comprises a time data 
field and wherein at least one connection setup means is 
provided with scheduling means for scheduling connection 
setup initiation in accordance with the content of a time data 
field. 

15. A method of operating a control apparatus, wherein 
the control apparatus is arranged to trigger an agreed set of 
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operations comprising at least one of a plurality of opera- 19. A method according to claim 18 wherein, in the case 

tions external to the apparatus and an operation comprising that the output signal comprises one or more combinations 
functionality of the control apparatus in combination with at of data elements, together with a condition indicator which 
least one of said plurality of operations external to the is different from the condition indicator of claim 18, the 

apparatus, the method comprising the steps: 5 second data processing means generates an output signal 

i) storing a set of data elements, at least one of said data wnicn comprises a response selected from 

elements comprising data defining an attribute of an d) a signal terminating communications between the data 
operation of the control apparatus in combination with processing means, and 

data defining an operation external to the control appa- e) a signal consisting of any one or more of the same 

ratus; 10 combinations. 

ii) allocating to each data element a weighting factor; 20. A method according to claim 16 wherein, in the event 

iii) receiving an input signal representative of a proposed L hat the 0Ut P ut si S nal comprises acceptance, the method 
set of operations, expressed in terms of at least one data further upases *e output of a control signal to control a 
element; P rocess or apparatus. 

.v C i j f t . t , . 4 . , «• f 15 21. A method according to claim 16 wherein, in the event 

iv) for each data element in the input signal, searching for t . ^ t . • , °- . . . . 4 , 

t , , t .-a. , / t ? . , . that the output signal comprises a signal comprising at least 

that data element in the stored set of data elements; „ f\, f ., , . ■ i- . , , • 

' one data element, said output signal is treated as an input 

v) for each data element of the input signal which is found s i gnal by lne se Con d data processing means and the second 
by the search in the stored set of data elements, data processing means repeats the method of claim 15, 
reviewing the weighting factor allocated to that data 20 outputting its output signal to the first data processing 
element; and means, the method being repeated in turn by the first and 

vi) generating an output signal, determined by the second data processing means until an output signal corn- 
reviewed weighting factors and representative of a prises either acceptance or rejection. 

response to the proposal, the response being selected 22. A method according to claim 15 wherein the steps of 

from agreement or rejection of the proposal or com- 25 reviewing the weighting factor allocated to each data ele- 
prising at least one data element representing a counter- ment and generating an output signal determined by the 
proposed set of operations. reviewed weighting factors, comprise selecting from the 

16. A method according to claim 15 wherein the review of stored data elements one or more data elements for which 
one or more weighting factors comprises summing the total the combined weighting factors are more favourable than the 
of the weighting factors and comparing the summed total 30 reviewed weighting factors) and the output signal com- 
with a stored value. prises the selected set. 

17. A method of processing data according to claim 15, 23. A method according to claim 17 wherein each input 
involving first and second data processing means, wherein and output signal which is transmitted between the data 
the input signal is received by the first data processing means processing means, and comprises at least one data element, 
from the second data processing means and the output signal 35 comprises a set of data elements which together define a 
is sent by the first data processing means to the second data control signal. 

processing means. 24. A method according to claim 20 and wherein the 

18. A method according to claim 17 wherein, in the case control signal comprises a connection setup signal for a 
that the output signal comprises one or more combinations communications network. 

of data elements, together with a condition indicator, the first 40 25. A method according to claim 23 wherein the set of 
data processing means stores a record of said combinations data signals which together define a control signal, define a 
and bars subsequent output signals by the first data process- connection configuration for use in the connection setup, 
ing means comprising any one or more of the same combi- 
nations. ***** 
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